A significant component of timing analysis involves the use of timing exceptions. A timing exception is a constraint that relaxes or tightens a timing relationship and the common forms of timing exceptions are multi-cycle paths, false paths, and minimum/maximum delay paths. In addition, timing exceptions can be assigned to/from clock domains (all registers or ports clocked by given clock), to/from individual ports or registers, through a given set of nodes, or any combination of these. For example, a register-to-register transfer can be relaxed to allow data to be captured in two clock cycles instead of one. This type of timing exception is commonly called a multi-cycle 2 exception, where “2” signifies the number of allowed clock cycles. The false path (or cut path) timing exception removes the path from the timing analysis, and can be treated as a multi-cycle exception with infinite cycles to capture data.
In many cases, a user can tailor timing exceptions to quickly constrain large groups of timing paths. This tailoring of timing exceptions, along with the use of wildcards and lists, makes it easy for timing exceptions to be applied to a large number of timing paths. The drawback of the ability to tailor timing exceptions is an increased likelihood of unintentionally applying the timing exception to extra paths. Therefore, it is often difficult to determine if a user over-constrained a design or if some timing exceptions erroneously override other timing exceptions. When timing exceptions are applied to a design, information of interest is whether the proper paths were constrained, no additional paths were constrained, or the timing exceptions were not incorrectly overridden by other timing exceptions.
It is in this context that embodiments of the invention arise.